1. Field of the Invention
The present invention relates to device management (DM), and more particularly to a method for addressing a management object in a management tree and an associated DM system.
2. Description of the Prior Art
In OMA (Open Mobile Alliance) DM (Device Management) protocol specification, when a DM server is to manage a management object (MO) of a DM client, the DM server will send addressing information to the DM client for addressing the MO in the management tree of the DM client. There are two types of addressing information: absolute universal resource identifier (URI) and relative URI. When the relative URI is received, the DM client performs an address translation to convert the relative URI into the absolute URI. In the OMA DM protocol, the relative URI contains two parts:
(1) Part A: This part is used to identify the root node of the MO to be managed. According to the part A, the DM client resolves the path which begins from the root of the management tree to the root node of the MO.
(2) Part B: This part is used to identify a target node within the MO. According to the part B, the DM client resolves the path which begins from below the root node of the MO to the target node.
The part A of the conventional relative URI can be defined as “URI?MOID=value&attribute=value”, and the description for each element therein is given below:
(a) URI: The URI parameter specifies a root node of a sub-tree of the management tree for finding the MO. That is, the DM client will find the MO occurrences in the whole sub-tree with the root node specified by the URI parameter. The URI parameter should be included in the relative URI addressing.
(b) ?: This element is used as the separator between the URI parameter and MOID, and must be included in the relative URI addressing only when the URI parameter is present.
(c) MOID=value: This element is the MO identifier used to specify the MO to be managed, and must be included in the relative URI addressing.
(d) &: This element is used as the separator between the MOID and the attribute condition, and may be included in the relative URI addressing.
(e) attribute=value: This element is used only when the DM server anticipates that multiple MO occurrences will be found. The ‘attribute’ identifies a specific leaf node directly under the root of the MO, and the ‘value’ identifies the value of the specific leaf node (in this specification, the leaf node means a node without any child node of its own). This element is used by the DM client to find the unique MO occurrence to be managed. If this element is specified, the preceding ‘&’ must be specified as well.
According to the specified MO identifier, the DM client will find all the MO occurrences in the whole sub-tree beginning from the URI parameter. In case there are multiple MO occurrences found and the element “attribute=value” is provided by the DM server, the DM client uses the “attribute=value” to resolve the root node of the unique MO occurrence to be managed, as shown in the example of FIG. 1. In FIG. 1, the DM server wants to manipulate the node ‘./A1/B/E’. The part A sent by the DM server is “.?[urn:oma:mo:oma_personal_data:1.0]&C=‘Phone’”. The part B sent by the DM Server is “B/E”. The resolved URI from the part A is “./A1” and the part B is “B/E”. Therefore, the actual URI of the node E is “./A1/B/E”. Then, the DM client is able to execute the node “./A1/B/E” as expected by the DM server.
However, there are several issues encountered when the above syntax definition of the conventional relative URI is used. The first issue is that, as described above, the element “attribute=value” is used to specify the unique MO occurrence in the management tree of the DM client, but when the number of MOs in the management tree increases, the element “attribute=value” may not be enough to specify the unique MO occurrence, as shown in the example of FIG. 2. In FIG. 2, there are three MOs under the root of the management tree. If the DM server wants to specify the ./A1/B/E, the relative URI will be “.?[urn:oma:mo:oma_personal_data:1.0]&C=‘Phone’” or “.?[urn:oma:mo:oma_personal_data:1.0]&D=‘Contact’”. Since both A1 and A3 have the leaf node C with the same value ‘Phone’, “.?[urn:oma:mo:oma_personal_data:1.0]&C=‘Phone’” cannot be used to specify a unique MO occurrence. Similarly, since both A1 and A2 have the leaf node D with the same value ‘Contact’, “.?[urn:oma:mo:oma_personal_data:1.0]&D=‘Contact’” cannot also be used to specify a unique MO occurrence. In this situation, the DM server won't have a relative URI to specify the node “./A1/B/E”.
The second issue is that when there is no leaf node directly under the root node of the MO, as shown in FIG. 3 (i.e. there is no leaf node under any of A1˜A3), the element “attribute=value” in the part A cannot be assigned by nature in the relative URI. Thus, in this situation, when the DM server wants to manage a MO and anticipates that multiple MO occurrences will be found in the management tree, the DM server can't use the conventional relative URI to specify the unique MO.